somewhat off-topic, but would it avoid boilerplate if the main/top-level core index.ts file instead just exports all notifications stuff under a notifications item? that has at least these advantages:

• avoids needing to update package.json
• avoids needing to create this file
• centralizes the index
• avoids consumers having to hunt for index files (they import one "mega index")

In addition to a top-level index.js, you would still need a lower level one to collect the individual files though right?
e.g.

src/notifications/index.ts

export * from 'controller.ts'
export * from 'types.ts'

src/index.ts

export * as notifications from 'notifications/index'

Maybe you could do this, but this looks like it would be very messy for many exports:

src/index.ts

import * as controller from './src/notifications/controller';
import * as types from './src/notifications/types';

export const notifications = {
  ...controller,
  ...types,
}

Also, not sure how autocomplete will behave. Needs investigation.

you would still need a lower level one to collect the individual files though right?
e.g.

no, could do that manually in the top level index.ts like this:

of course, this means the top level has to "choose" some names, but in practice that doesn't seem to be a problem, and it may actually lead to a better interface for the consumers.

So then you have pretty granular exports anyways, right? e.g.

export * as notificationsTypes from './src/notifications/types'
export * as notificationsRules from './src/notifications/rules'
export * as notificationsController from './src/notifications/controller'

which isn't as intuitive as a single notifications export from all of these places.

True, though it depends on what consumers actually need. Generally we shouldn't need to expose most modules in the "public" interface.

Tracked in https://taskei.amazon.dev/tasks/IDE-15174